Yeah I think this mockup looks good to me. Then the new module is just the logic from #100?

yes, i forced pushed since i forgot the file...

Since this is a sysvar though should this happen automagically inside mollusk setup? Rather than being an account people must add

Since this is a sysvar though should this happen automagically inside mollusk setup? Rather than being an account people must add

Yep I think so! Typically I try to avoid overwriting user-provided accounts, even if it's a special account like this one. So we should make sure we first check if the account was provided already, and if it was not, then do this setup logic.

That being said, the harness does one allocation for the provided accounts slice when it creates a list of "transaction accounts" from the account compilation step.

So I'm thinking maybe we can push it into the accounts list here? This way it's in the transaction accounts list before we even create the TransactionContext and do the set_top_level_instruction_index step.

I'm open to whether or not we should include the auto-populated Instructions Sysvar account in the resulting accounts list. I can go either way: return it or cut it out.

Since this is a sysvar though should this happen automagically inside mollusk setup? Rather than being an account people must add

Yep I think so! Typically I try to avoid overwriting user-provided accounts, even if it's a special account like this one. So we should make sure we first check if the account was provided already, and if it was not, then do this setup logic.

That being said, the harness does one allocation for the provided accounts slice when it creates a list of "transaction accounts" from the account compilation step.

mollusk/harness/src/lib.rs

Lines 683 to 687 in 1cfdd64

	let CompiledAccounts {
	program_id_index,
	instruction_accounts,
	transaction_accounts,
	} = crate::compile_accounts::compile_accounts(instruction, accounts, loader_key);

So I'm thinking maybe we can push it into the accounts list here? This way it's in the transaction accounts list before we even create the TransactionContext and do the set_top_level_instruction_index step.

I'm open to whether or not we should include the auto-populated Instructions Sysvar account in the resulting accounts list. I can go either way: return it or cut it out.

It can't be that deep because the process_instruction function only knows about the current instruction...

It can't be that deep because the process_instruction function only knows about the current instruction...

Ah yes, you're right...

How about this? I set up a PR that should decouple things enough for you to stick this step right before the account compilation step and use a chained iterator to feed compile_accounts. We also need the index setting step as well, and I'll review the Agave PR asap.

#157

Let me know if this works for you!